ASM Static Analysis Methodology Version 0

Abstract

A methodology written to structure the stability verification of an assembly written program.

Introduction

For a program written in assembly, writing normal tests can be unnecessary or not optimal due to the effort-to-reward ratio. Which is expected given what the programmer has to manage in assembly, yet the programs have to be stable. In order to verify the stability of a written program, this methodology is to provide the tooling to apply the rigor necessary.

Terminology

• Flag: In this document, a flag is defined as the subject of focus (always an assembly code). For example, if analyzing a subject, the flag is the subject.

• Necessary: Necessary has its standard meaning, yet the definition of the necessary is given by (a) previous argument(s).

1.0 Categories

Flags can be within categories, those which allow for proper handling of the conclusion of the analysis. For a flag to fit in a category, one has to be match the conditions described in the category section.

1.1 Satisfactory

Is considered satisfactory a flag of which, given a logic, attends to it without violating the logic, and having all the methodology steps followed in order of validating those conditions.

1.2 Slow

A slow flag is one which has within more than zero operations being done with more instructions than necessary, while the higher count of instructions is not optimal. Or when the flag has more than zero operations done with unnecessary dependency chains throughout the instructions.

The slow flag does not account for algorithmic slowness, or instances regarding the absence of SIMD paths because it would make the development of the methodology unnecessarily complex: a competent developer should be able of knowing that, for example missing a cache line is expensive performance-wise.

1.3 Problematic

A problematic category is given to flags of which follow the said logic, but can conditionally fail.

1.4 Error

A flag is in the error category if the instructions in the flag act disregarding the logic, hence a guaranteed failure.

1.5 Tenderly cute

A flag in the tenderly cute category is one, which opposed to the slow flag uses only the enough count of instructions for executing the logic, and does not create unnecessary dependency chains.

2.0 Logical description

By analysing a flag, it is necessary to first define what logic it is expected to execute. As the logic is being described, every branch must be defined, as have a logical description of its own. The leading path after the branch must be a flag of its own, with the methodology applied on it.

On the description, all the states of the registers must be traced. If a register starts the flag with a predefined value, it must be either stated, or in case of it being result of another flag: referenced.

A branch is only considered a Jcc thus CMOVcc is not. A call is not hereby considered a branch because it is not conditional; hence possible to keep the leading logic with the state of the returning registers. That being said, it is more coherent to start the analysis with the standalone flags.

Note: For a “pretty” document, it is recommended to state the line range of the code where the flag is in; including the file name which the flag is in.

3.0 Mathematical rigor

As tracing the logic, it is mandatory to describe the logic with a math that represents it; hence the logic being followed must be proven mathematically. Whereas it has to be described either in GNU Octave code, or bare linear algebra.

A register, SIMD register, or x87 register, must be treated as matrices. Whereas in R_ij i is the bit count of the lane, and j the lane count. A non-SIMD register has only a single lane, whereas xmm has two of 64-bits, and so on.

If a said operation cannot be reasonably defined with math, a polynomial that emulates the behavior, or argumentation with citations from sources such as Intel SDM or relatives (for the target chip) can be done.

4.0 Proper conclusion and pragmatism

As writing the static analysis, a codebase may be filled with flags in unpleasing categories. In such cases, if the other flags to be analysed depend on the unpleasing-categorized flag those can be skipped for the specific analysis. Yet it is a good practise to make the decision explicit for the reader, so the document can have both the rigor it is built to have, and a good readability for peers.